The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Computing devices often process multiple types of media. The media that may be processed by computing devices often include numerous forms and formats of video, and numerous forms and formats of audio. Within such computing devices, many applications may be competing for media input or playback. Examples of the types of applications that may attempt to play or input media within a handheld computing device include, for example, a telephone application, a web browser, an e-mail application, a short message service (SMS), a music player, a video player, instant messaging (IM) application, a multimedia message service (MMS), a voice over IP (VOIP) application, and a teleconferencing application.
Within computing devices, the various software applications that utilize media all contend for use of the various input or output resources, and have different rules and protocols for doing so. Some of these rules and protocols may conflict from one application to another.
To complicate matters further, many computing devices also have multiple possible inputs and outputs for routing audiovisual information. For example, a handheld computing device may have a line-out port, a headphone port, a docking port, a microphone, a line-in port, a wireless connection, and multiple built-in speakers, each of which may serve a different function and have different capabilities.
One way to handle the contention among the applications for the playback resources of a computing device is to design each application with logic to check the state of settings of the device and decide for itself where, when, and how to play its audiovisual information. Unfortunately, using this approach, each software application developer must implement code for a behavior tree that attempts to take into account the variety of factors that can impact media processing on a device. The result may be less-than-optimal media handling decisions made by more-complex-than-necessary applications.
Further complicating the routing of audiovisual information, it may be desirable to have the information processed in specific ways under specific circumstances. For example, when music and voice audio are to be played concurrently, it may be desirable to mix the music and voice audio in a particular way. Typically, such custom treatment of specific cases would be hard-coded into the logic of the software and/or hardware components involved in the playback. Hard-coding such customizations significantly increases the complexity of a devices software and/or hardware components.
Additional complications arise when a device is connected to one or more wireless inputs or outputs, such as bluetooth headsets. While many conventional devices simply assume that audiovisual information should be routed through wireless connections whenever possible, a user may often prefer not to route audio through a connected device. For example, the user may have inadvertently entered into the range of such a device. Many conventional devices would automatically assume that audio should be transferred to the wireless device, even though the user may in fact not be in a position to even hear the device.
Further complications arise in managing certain accessory devices that include several logical inputs or outputs—such as Bluetooth headsets that implement multiple audio protocols—or in managing groups of inputs and outputs that have complementary uses—such as a headset and a microphone. Users and software developers alike find management of such groups of inputs and outputs confusing and tedious.